-
Notifications
You must be signed in to change notification settings - Fork 401
Expose Command collection properties as mutable IList, remove AddCommand, AddOption and AddArugment methods #1989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
use a custom type that implements IList to ensure that on every added element the parent is set as well
|
||
internal bool HasArguments => _arguments is not null; | ||
|
||
/// <summary> | ||
/// Represents all of the options for the command, including global options that have been applied to any of the command's ancestors. | ||
/// </summary> | ||
public IReadOnlyList<Option> Options => _options is not null ? _options : Array.Empty<Option>(); | ||
public IList<Option> Options => _options ??= new (this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public IList<Option> Options => _options ??= new (this); | |
public IList<Option> Options => _options ??= new(this); |
...ility.Tests/ApiCompatibilityApprovalTests.System_CommandLine_api_is_not_changed.approved.txt
Show resolved
Hide resolved
/// <summary> | ||
/// a wrapper of List<typeparamref name="T"/> that sets parent for every added element | ||
/// </summary> | ||
internal sealed class ChildList<T> : IList<T> where T : Symbol |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider this?
internal sealed class ChildList<T> : IList<T> where T : Symbol | |
internal sealed class ChildList : IList<Symbol> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be impossible to enforce the right types without perf overhead. Example:
Option<bool> option = new ("--some);
RootCommand root = new ();
// in the line below Arguments would be a list of Symbols, which would allow for adding not just arguments but also options and commands
root.Arguments.Add(option); // no compilation error, at runtime we would later find out that it's not an Argument
@@ -113,26 +82,32 @@ public void AddOption(Option option) | |||
public void AddGlobalOption(Option option) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is weird that now that you are removing AddOption
we keep AddGlobalOption
. If we follow the pattern this should be named AddGlobal
, no? But that sounds weird.
Not asking for a change, just wanted to point that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is on my TODO list, we just need to find a good name for "global" options. In the near future it might look like this:
Option<bool> help = new ("--help);
help.IsCommon = true;
command.Options.Add(help);
# Conflicts: # src/System.CommandLine.ApiCompatibility.Tests/ApiCompatibilityApprovalTests.System_CommandLine_api_is_not_changed.approved.txt
I believe I've answered all the questions, merging. |
This is very similar to #1987, but since adding a new Symbol to Command requires setting a parent I had to implement a custom
IList<T>
that sets the parent on every add.